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1. INTRODUCTION 

This Quarterly Technical Report No. 7 describes several 
aspects of our technical progress on the ARPA Computer Network 
during the third quarter of 1970- 

• During this period, we installed IMPs No. 10 and No. 11 
at Lincoln Laboratories and Stanford University, commenced 
experimental testing with 230.4 kilobit/sec circuits in the 
test cell at BBN, and completed retrofits of new control panels 
and auto restart circuitry. 

• We developed a new version of the operational IMP pro¬ 
gram (IMPSYS 24) for release in November 1970. The organization 
of the IMP program has been substantially changed from the pre¬ 
vious operational program to allow a large number of modifica¬ 
tions to be efficiently incorporated. This activity is described 
in Section 2. 

• A primary development effort during this quarter has been 
directed toward the preliminary design of the terminal IMP. 

Initial logic design has been completed for a multi-line con¬ 
troller that will handle up to 64 asynchronous or synchronous 
terminal devices, and all standard codes and speeds. In ad¬ 
dition, we have produced preliminary coding of the inner loop 

of the terminal IMP program. This effort is described in Section 3* 
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• The Network Control Center has now been in operation for 
over three months. This effort has progressed particularly 
smoothly. A mlni-Host was constructed in the prototype IMP for 
use by Network Control Center personnel in obtaining hourly 
summaries of network performance. A sample of this summary 
information is presented in Section 4. 

• We have continued to participate in discussions of Host 
protocol. Several modifications have been made to the IMP pro¬ 
gram to conform with the Host protocol. In addition, we formu¬ 
lated an alternate Host protocol scheme. This activity is 
described in Section 5. 
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2. IMP PROGRAM DEVELOPMENT 

During this quarter, the operational IMP program was ex¬ 
tensively revised. Revision was necessary to the efficient 
incorporation of many new system features and to modifications 
in the new version of the IMP Program (IMPSYS 24), scheduled 
for release in November. 

New system features include a single line test message 
that each IMP transmits to its neighbors at half-second inter¬ 
vals. All routing, HELLO, and I HEARD YOU information is com¬ 
bined and transmitted in this single message. Previously, 
these three line test messages were transmitted separately. 

The quality of a given line is now measured by the number of 
line test messages which fail to get through on that line in a 
time interval of approximately one minute. 

A remote crosspatching feature was incorporated to allow a 
selected interface or modem to be looped under control of the 
operational IMP program. This capability enables the Network 
Control Center to locate accurately the source of most field 
problems. IMP personnel can now isolate a faulty communication 
line, a faulty modem, and most hardware interface problems 
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directly from the Network Control Center. However, the on-site 
assistance of Honeywell or telephone company personnel is still 
1 required for subsequent diagnosis and repair. 

The long-term timeout period was reduced from 15 minutes 
to one minute. This reduction involved careful attention to 
timing in each of the major system routines to insure that the 
sequence of time-out mechanisms involving one or more IMPs 
would be executed in the proper order. 

Approximately a hundred minor revisions have been made to 
the IMP program. For example: 1) partially reassembled mes¬ 
sages are now discarded when their source goes dead; 2) the Host 
can no longer use all the IMP'S buffers by causing error mes¬ 
sages to be generated but not accepting them; 3) an IMP may be 
induced to reload from a specific line instead of a random line; 
4) the IMP number is not changed when an IMP is reloaded with 
its memory protect switch in the off position; 5) the Host 
routines may be put in a hardware test mode by the control 
center to facilitate Host debugging; 6) all phone lines are 
initialized to be down rather than up. 


4 



Report No. 2059 


Bolt Beranek and Newman Inc. 


3. TERMINAL IMP 

We have begun to work on the design of a terminal IMP that 
will serve the dual function of an IMP and a terminal device 
handler. It will provide a capability for direct connection 
of terminals into the net. Specifically, the terminals need 
not be connected to a Host computer; but, rather, they may 
access any remote Host computer via the terminal IMP and the 
network. 

A brief description of our initial design for the terminal 
IMP and its device handling capabilities, as presently envis¬ 
ioned, is given below. Built into the terminal IMP will be a 
multi-line controller capable of handling up to 64 terminal 
devices. The controller provides all of the logic for assembly 
and disassembly of characters and for transferring characters 
into and out of the IMP’S memory. Both synchronous and asyn¬ 
chronous lines can be handled, the practical distinction being 
whether or not the controller must provide the clocking signal. 
All input characters must be of "asynchronous format" in that 
both start and stop bits are required by the terminal IMP. Out¬ 
put characters will also be provided in "asynchronous format" 
to each terminal on either synchronous or asynchronous con¬ 
nections. Character sizes of from five to eight bits can be 
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handled. The program will be able to set ’noth, the character 
size and speed for each device, thus enabling the program to 
determine the type of terminal connection and permitting a 
number of options, such as a dial-up capability, to be proyided. 

A terminal device may be operated on input or output at 
speeds up to and including 19.2 kilobits/sec. However, no more 
than 10 devices may have speeds exceeding 2400 hits/second; 
the remaining devices must all be operated at speeds of 2400 
bits/second or less. The overall bandwidth of the terminal IMP 
for combined input and output is limited by the program's capa¬ 
bility to process characters. Present estimates are that the 
terminal handling bandwidth will be about 100 kilobits/second. 

The interface to the terminals will conform to the RS232 
standard. A terminal device may be directly connected to the 
multi-line controller or a device may be remotely connected via 
a modem. Several standard modem types will be available on 
cards that can be housed in the terminal IMP enclosure. 

We have begun preliminary work on the program design for 
the terminal IMP. Our initial estimates, based on the Honey¬ 
well H-316, indicate that the inner loops of both the input 
and output sections require about 50 cycles to process a 
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character. The central task on output Is to handle the trans¬ 
fer of packed characters from a single buffer one at a time 
out a multiplexed DMC channel. The central task on input is 
to pack input characters and to monitor the input for mode 
changes. The programs must also provide echoing, do character 
conversion if needed, and must process user-specified infor¬ 
mation such as the message destination. 
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4. NETWORK CONTROL CENTER 

During the last quarter, the Network Control Center (NCC) 
maintained the ARPA Network, scheduled time as appropriate for 
network maintenance and testing, and coordinated activities 
among Honeywell, the telephone company, and the sites. 

A standard procedure was developed for site personnel to 
report trouble or repairs directly to the control center. In 
most instances, requests for use of the IMP to perform main¬ 
tenance or testing have been easily coordinated through the 
control center. At any given time, the NCC has fairly complete 
knowledge of the current and expected state of the network, and 
as such is usually able to deal straightforwardly with most 
problems that arise. 

Status information on the lines and IMPs in the net is 
printed on the IMP teletype at BBN as received from each IMP 
in the net. The NCC has been using this information as a 
standard reference for monitoring network status. 

The Network Control Center has also implemented a program 
to provide hourly summaries of network performance. This pro¬ 
gram has led to a simplification in the procedures for monitor¬ 
ing the net, has improved upon the capabilities for detecting 
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status changes, and has provided a more convenient means of 
recording information. We plan to improve the capabilities of 
this program during the next quarter. 


A sample of the summary output is illustrated below.: 
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A mini-Host system was implemented in the prototype IMP in 
which this program and several other useful programs are run. 

The prototype IMP is currently connected to BBN' s regular IMP. 
The operational IMP program at BBN has been temporarily patched 
so that all messages to BBN's teletype are copied and passed to 
the prototype, which in turn examines each received message and 
processes only the trouble reports. 

Every hour on the hour, a summary report is printed show¬ 
ing: 1) the status of each IMP in the net at the beginning of 
the hour and each subsequent change in status; 2) similar 
status information for all lines in the net; and 3) a cumulative 
sum of line errors for each line during the hour. 

In the current version of the program, an IMP is said to 
be up only if a status report has been received from the IMP 
within the last 20 minutes. A line is said to be up if the IMPs 
at both ends of the line report it to be up. 


1 0 



Report No. 2059 


Bolt Beranek and Newman Inc. 


5. HOST PROTOCOL 

Two new control message types, cease sent and retract cease , 
were added to the IMP/Host Protocol to conform with the Host-to- 
Host Protocol. The cease sent Is presented to the Host whenever 
a cease on link RFNM is constructed. The retract cease message 
negates the effect of a cease message if it can. 

To assist the Hosts in their debugging efforts, we have 
modified the IMP program to discard any Host messages sent on a 
blocked link. A blocked, link error message is returned to the 
Host. Previously, the message was not discarded, and the Host 
line was hung for 15 minutes in this situation. One consequence 
of this change is that messages sent on blocked links from the 
real Host will be discarded to unblock the Host interface; mes¬ 
sages sent on blocked links from a Fake Host will hang the Fake 
Host until the link is unblocked. 

In Network Working Group 67 a change to the IMP program 
was proposed that would have resulted in the leader of a message 
being sent as a separate message before the text in all communi¬ 
cation between the Host and its IMP. We believe that this change 
could have simplified the Host message handling procedures. 
Although this proposed change met with general approval, it 



Report No. 2059 


Bolt Beranek and Newman Inc. 


would have introduced a negative transient in some Host efforts 
to achieve timely use of the net. We are therefore no longer 
considering this change at this time. 

A Host protocol document entitled "Interprocess Communica¬ 
tion in a Resource Sharing Network" was generated by David Walden 
in an effort to provide some fresh insights into this area. The 
scheme described in this document is philosophically different 
from the Protocol currently under implementation for the ARPA 
Network. 

In this protocol scheme, connections are non-permanent 
entities that are established each time a message is communicated 
between processes. Each message carries a complete set of 
identification information, including the receive and send socket 
pair. A rendezvous scheme, that permits dynamic reconnection to 
occur, is an intrinsic part of the basic communication procedure. 
Although this scheme is not suitable for incorporation with the 
current protocol implementation for the ARPA Network, it is a 
document worthy of study for possible application to future 


protocol efforts. 
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